Modern computing systems comprise components that are combined to achieve efficient scaling of distributed computing resources, distributed data storage resources, distributed networking resources, and/or other resources. Such distributed systems have evolved in such a way that incremental linear scaling can be accomplished in many dimensions. The resources in a given distributed system are often grouped into resource subsystems, such as clusters, datacenters, or sites. The resource subsystems can be defined by physical and/or logical boundaries. For example, a cluster might comprise a logically bounded set of nodes associated with a certain department of an enterprise, while a datacenter might be associated with a particular physical geographical location. Modern clusters in a distributed system might support over one hundred nodes (or more) that in turn support as many as several thousands (or more) autonomous virtualized entities (VEs). The VEs in hyperconverged distributed systems might be virtual machines (VMs) and/or executable containers, in hypervisor-assisted virtualization environments and/or in operating system virtualization environments, respectively. System administrators or other users (e.g., code developers) of the VEs rely on VE identifiers (VEIDs) to refer to a given VE for various purposes. For example, a system administrator might use VEIDs to monitor performance and/or activity pertaining to a particular one of, or set of VEs in the system. As another example, a code developer might use a VEID as a literal name in a script or application (e.g., to invoke or otherwise address a particular VE).
Unfortunately, legacy techniques for managing virtualized entity identifiers based on user-generated VEIDs can conflict with other user-generated VEIDs. Specifically, certain legacy approaches allow any number of users (e.g., system administrators, application developers, script developers, etc.) to manually specify the VEID. For example, a first system administrator might specify his/her VEID (e.g., “MyVEID1”) when the VE is created, while a second system administrator might specify his/her VEID (e.g., “MyVEID1”) for some purpose. With such manual approaches, duplicate VEIDs within a cluster or across clusters can be present. Conflicts can occur at random moments in time (e.g., whenever an administrator specifies a VEID), and then can be codified into the code base, and then can be propagated throughout the cluster or site. For example, when a script referencing a certain VE identified as “VEID05” from one resource subsystem, such as cluster C01, is deployed to another resource subsystem, such as cluster C02, that already has a different VE that is also identified as “VEID05” (e.g., by another system administrator or developer), a conflict arises. In this case, the script may fail and/or may not perform properly (e.g., it may return incorrect data). Further, the foregoing legacy techniques risk VE identifier conflicts in hyperconverged distributed systems that include centralized access points. Specifically, as an example, a multi-cluster centralized dashboard application might display the performance or other information of VE “VEID05”, however that information might include information from two or more VEs that are referenced by the same (conflicted) identifier “VEID05”.
What is needed is a technique or techniques to improve over legacy techniques and/or over other considered approaches. Some of the approaches described in this background section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.